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1.0  INTRODUCTION 

This  chapter  explains  the  purpose  of  the  convention,  the  scope  of 
the  guidance,  and  provides  an  explanation  of  how  to  use  the 
convention. 

1.1  PURPOSE  OF  THE  CONVENTION 

The  convention  provides  general  guidance  on  the  implementation 
of  American  National  Standards  Institute  (ANSI)  Accredited  Stand¬ 
ards  Committee  (ASC)  X12  electronic  data  interchange  (EDI) 
standards  within  automated  information  systems  (AIS)  and  infor¬ 
mation  interchange  procedures  that  require  the  collection,  report¬ 
ing,  and/or  exchange  of  data  needed  to  perform  defense  missions. 

1.2  SCOPE 

The  guidance  is  provided  for  two  components.  First,  it  may  Ic 
used  by  organizational  elements  of  the  DoD  community.  It  may 
also  be  useful  to  organizations  external  to  DoD  that  exchange  data 
with  the  DoD  community  in  the  course  of  their  business  relation¬ 
ships. 

The  DoD  community  encompasses  the  Military  Services,  Organiza¬ 
tions  of  the  Joint  Chiefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  referred  to  as  the  DoD  Components.) 

Organizational  entities  external  to  DoD  include  (a)  non-Govem- 
ment  organizations,  both  commercial  and  nonprofit;  (b)  Federal 
agencies  of  the  United  States  Government  other  than  DoD; 
(c)  local  and  state  governments;  (d)  foreign  national  governments; 
and  (e)  international  government  organizations. 

The  draft  convention  published  in  this  document  is  for  trial  use 
and  comment.  DoD  Components  must  submit  to  the  DoD  EDI 
Executive  Agent  (EA)  their  data  requirements  that  are  not  covered 
in  the  conventions  as  soon  as  possible,  as  indicated  in  Chapter  2.0, 
Section  2.1. 

1.3  RESPONSIBLE  ENTITY 

The  Defense  Logistics  Agency  (DLA)  is  DoD’s  Executive  Agent 
for  implementing  and  maintaining  Defense-wide  programs  for 
(a)  EDI  in  accordance  with  DepSecDef  memorandum  of  May  24, 
1988,  Subject:  Electronic  Data  Interchange  of  Business-Related 
Transactions;  and  (b)  Protection  of  Logistics  Unclassified/Sensi¬ 
tive  Systems  (PLUS)  in  accordance  with  Assistant  Secretary  of 
Defense  (Production  and  Logistics)  [ASD(P&L)J  memorandum  of 
November  21,  1989,  Subject:  Production  and  Logistics  Task 
Group  for  Data  Protection.  Publication  of  these  conventions  is 
based  upon  this  authority.  See  Chapter  2.0  Maintenance,  Section  2.1 
for  office  point  of  contact 
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1.4  HOW  TO  USE  THE  IMPLEMENTATION 
CONVENTION 

The  main  topics  and  structures  of  this  document  conform  to  the 
EDI  Implementation  Reference  Manual  Guidelines  document  that 
was  developed  by  a  task  group  of  the  subcommittee  on  education 
and  implementation  of  the  ASC  X12.  The  purpose  of  having 
agreed-upon  topics  and  structure  is  to  facilitate  reference  by  the 
many  industry  and  DoD  personnel  who  are  involved  in  implement¬ 
ing  the  uniform  standards  for  electronic  interchange  of  business 
transactions. 

1.4.1  Conventions,  Standards,  and  Guidelines 

The  terms  conventions,  standards,  and  guidelines  are  used 
throughout  the  document  and  are  defined  as  follows: 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  AS C  X12  standards.  Conventions  define  what  is 
included  in  a  specific  implementation  of  an  ASC  X12  standard. 

•  Standards  are  the  technical  documentation  approved  by 
ASC  X12;  specifically,  transaction  sets,  segments,  data  ele¬ 
ments,  code  sets,  and  interchange  control  structure.  Standards 
provide  the  structure  for  each  ASC  X12  document. 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI.  Guidelines 
are  intended  to  provide  assistance  and  should  not  be  your  sole 
source  of  information. 

1 .4.1 .1  Who  Develops  the  Conventions? 

Conventions  result  from  a  joint  effort  between  business,  technical, 
and  EDI  ASC  X12  standards  experts.  The  business  data  require¬ 
ment  is  defined,  a  transaction  set  is  selected,  and  the  data  require¬ 
ment  is  then  identified  with  data  elements  in  the  transaction  set. 
A  convention  is  usually  developed  before  any  computer  EDI  sys¬ 
tems  development  work  and  serves  as  a  design  document  when  the 
development  process  begins. 

1.4.1 .2  Why  Use  a  Convention? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  X12  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  this  task  is  contained  in  the  convention 
document.  Users  who  follow  the  convention  will  create  a  transac¬ 
tion  set  that  all  DoD  users  understand. 

1.4.1 .3  Who  Needs  a  Convention? 

System  analysts  and  application  programmers  who  plan  to  create 
or  read  ASC  X12  transactions  use  a  convention  to  aid  in  interface 
software  design.  The  convention  will  help  the  programmer  and 
analyst  identify  where  their  application  data  requirement  should  be 
carried  in  an  ASC  X12  transaction  set. 
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1 .4.4.4  Can  I  Develop  a  Convention? 

Conventions  already  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization’s  EDI  coordinator  at  the  start  of  an  EDI  project. 
If  you  find  no  conventions  for  the  business  practice  you  are  about 
to  implement,  your  EDI  coordinator  should  contact  the  DoD  Ex¬ 
ecutive  Agent  for  EDI.  See  Chapter  2.0,  Maintenance,  Section  2.1 
for  the  point  of  contact. 

1.4.2  Documentation  of  Conventions 

Conventions  are  adopted  from,  and  are  intended  to  be  in  confor¬ 
mance  with,  ANSI  ASC  X12  standards  or  ASC  X12  Draft  Stand¬ 
ards  for  Trial  Use  (DSTU). 

1. 4.2.1  Transaction  Set 

Figure  1.4-1  provides  an  example  of  a  transaction  set  table.  The 
transaction  set  defines  information  of  business  or  strategic  sig¬ 
nificance  and  consists  of  a  transaction  set  header  segment,  one  or 
more  data  segments  in  a  specified  order,  and  a  transaction  set 
trailer  segment.  The  actual  ASC  X12  standard  as  it  appears  in  the 
official  ASC  X12  standards  manual  is  presented  on  the  right  side 
of  the  page.  This  standard  also  includes  both  syntax  notes  and 
comments.  The  specific  DoD  usage  designator  is  presented  on  the 
left  side  of  the  page. 

The  designation  “N/LT  appears  in  the  left  column  if  DoD  does  not 
use  the  specific  segment.  A  page  number  will  appear  if  the  segment 
is  used. 

1. 4.2.2  Transaction  Set  Segment 

Figure  1.4-2  is  an  example  of  a  transaction  set  segment. 

DoD  usage  is  specified  on  the  leti  side  of  the  page.  For  identifier 
(ID)  —  type  data  elements,  acceptable  code  values  are  listed  on 
the  right  side  of  the  page  under  the  definitions  of  the  element. 

DoD  notes,  reflecting  how  the  convention  is  to  be  used  appear  on 
the  right  side  of  the  page  at  the  segment  level  or  the  data  element 
level. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  DoD-specific  segment 
directory  section  of  the  convention.  For  ASC  X12  usage,  see  the 
definitions  in  X12.6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  are  defined  by  ASC  X12. 

•  Optional 

Optional  data  elements  are  used  at  the  discretion  of  the  sending 
party  or  are  based  upon  mutual  agreement  between  trading 
partners. 
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g'M  Application  Advice 

This  standard  provides  the  format  and  establishes  the  data  contents  ot  the 
Application  Advice  Transaction  Set  (824)  within  the  context  ot  an  Electronic 
Data  Interchange  (EDI)  environment.  This  transaction  set  provides  the  ability 
to  report  the  results  of  an  application  system  s  data  content  edits  ot 
transaction  sets.  The  results  of  editing  transaction  sets  can  be  reported  at  the 
functional  group  and  transaction  set  level,  in  either  ooded  or  free-torm  format. 
It  is  designed  to  accomodate  the  business  need  of  reporting  the  acceptance, 
rejection  or  acceptance  with  change  ot  any  transaction  set.  The  Application 
Advice  should  not  be  used  in  place  of  a  transaction  set  designed  as  a 
specific  response  to  another  transaction  set  (e.g..  purchase  order 
acknowledgement  sent  in  response  to  a  purchase  order). 
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BGN  •  BEGINNING  SEGMENT  ANSI  ASC  X12  VERSION/RELEASE  003010000. 


Mandatory 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Syntax: 
Comments: 


BGN  Beginning  Segment 

Header 

Mandatory 

1 

To  indicate  the  beginning  of  a  transaction  set. 

If  BGN05  is  used.  BGN04  is  required. 

1.  BGN02  is  the  Transaction  Set  Reference  Number. 

2.  BGN03  is  the  Transaction  Set  Date. 

3.  BGN04  is  the  Transaction  Set  Time. 

4.  BGN05  is  the  transaction  set  time  qualifier. 


Mandatory 


Mandatory 


Mandatory 


Conditional 


NotUaod 


Data  Element  Summary 


BQNOi  353  Transaction  Set  Purpose  Code 

Cods  identifying  purpose  ot  transaction  set. 

00  Original 
01  Cancellation 
04  Change 
12  Not  Processed 


ID 


2/2 


BON02  127 


BGN03  373 


BQN04  337 


Reference  Number  M  AN 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  at  specified  by  the  Reference  Number  Qualifier. 


1/30 


Date 

Date  (YYMMOD). 


M  DT  6/6 


Time  C  TM  4/4 

Time  expressed  in  24-hour  dock  time  (HHMM,  time  range:  0000  though  2359). 


Implomontotlon  Not o: 

Use  HHMM. 

BONOS  623  Time  Code 


2/2 
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Figure  1.4-2  Example  of  a  Transaction  Set  Segment 
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•  Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules,  but  are  required  by  DoD  decision. 

•  Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  DoD,  but  the  industry  recommends 
their  use  to  facilitate  EDI.  Most  companies  in  the  industry 
are  expected  to  use  this  data  element. 

•  Not  Used 

“Not  Used"  data  elements  are  those  that  the  DoD  does  not 
use. 

•  Conditional 

Conditional  data  elements  depend  on  the  presence  of  other  data 
elements  in  the  transaction  set. 
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2.0  MAINTENANCE 

This  chapter  describes  the  procedures  for  maintaining  the  DoD 
conventions.  It  also  presents  a  section  on  version/release  timing. 

2.1  MAINTAINING  CONVENTIONS 

The  DLA,  as  DoD’s  Executive  Agent  for  EDI  and  PLUS,  has 
established  a  joint  program  office  to  oversee  implementation  of 
EDI.  Some  of  the  functions  oi  this  program  office  are  to  maintain 
configuration  control  of  related  standards  and  common  support 
packages  (e.g.,  versions  of  ASC  X12  standards  and  PLUS  algo¬ 
rithms  employed),  participate  in  the  standards-setting  process,  and 
ensure  compliance  with  approved  EDI  standards. 

To  accomplish  these  functions,  the  joint  program  office  has  estab¬ 
lished  a  conventions  and  standards  development  and  maintenance 
process  whose  objectives  are:  (1)  to  obtain  ASC  X12  data  require¬ 
ments  from  the  DoD  Components  and  present  the  requirements  to 
the  ASC  X12  for  consideration  as  ANSI  standards,  and  (2)  to 
develop  and  maintain  conventions  for  use  by  DoD  Components 
and  their  potential  trading  partners. 

To  take  advantage  of,  and  not  duplicate,  existing  data  stan¬ 
dardization  processes,  the  EA  has  established  focal  points 
within  the  ASD  Offices,  the  Military  Services,  and  the  Defense 
Agencies  from  which  EDI  information  is  obtained  and  dissemi¬ 
nated. 

The  EA’s  primary  source  of  information  about  DoD’s  data  require¬ 
ments  is  the  EDI  User. 

Changes  to  this  publication  and  recommended  changes  to  ANSI 
ASC  X12  should  be  forwarded  through  your  organizational  point 
of  contact  for  data  standardization  to: 

EDI  Standards  Coordinator 
ATTN:  DLA-ZC 
Cameron  Station 
Alexandria,  VA  22304-6100 

See  Chapter  4  for  reproducible  ASC  X12  Work  Request  forms. 

2.2  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version”  of  a  standard  is  critical  to 
the  successful  interchange  of  information.  Each  participant  must 
be  able  to  send  and  receive  the  same  version  to  ensure  the  accuracy 
of  the  information  exchanged. 

The  version  is  transmitted  as  a  12-character  code  in  the  Functional 
Group  Header  segment  (GS)  in  Data  Element  #480,  Ver¬ 
sion/Release/Industry  ID.  This  12-character  code  is  used  by 
ASC  X12  as  follows. 
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Position 

Content 

1-3 

Version  number 

4-5 

Release  level  of  version 

6 

Subrelease 

7-12 

DoD/Industry  or  Trade  Association  ID 

ASC  X12  assigns  the  codes  in  positions  1  through  6. 

A  major  version  (1-3)  will  change  only  after  an  official  public 
review  cycle,  leading  to  republication  of  a  new  American  National 
Standard. 

Release  level  of  each  new  major  version  (4-6)  will  begin  at  “000” 
and  incremented  by  1  for  each  new  ASC  X12  approved  publication 
cycle,  usually  once  a  year.  The  fifth  character  designates  the 
release  and  the  sixth  character  designates  the  subrelease. 

DoD/Industry/Trade  Association  ID  (7-12)  is  used  to  identify 
conventions.  For  this  suffix,  DoD  will  use  “DoD_”  with  the  10th 
character  identifying  successive  publications.  The  11th  and  12th 
characters  may  be  used  by  the  Military  Departments  or  Defense 
Agencies. 

DoD  conventions  for  using  ASC  X12  standards  are  published 
annually.  Conventions  developed  for  each  release  will  be  main¬ 
tained  for  4  years.  Military  Services  and  DoD  Agencies  will 
determine  which  release  to  use  on  the  basis  of  business  need  but 
will  not  use  any  release  more  than  4  years  old  without  approval 
of  the  DoD  EA. 
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3.0  DoD  CONVENTIONS  FOR  USING 
ASC  X12  TRANSACTION  SETS 

This  chapter  defines  the  DoD  transaction  set  conventions.  It 
includes  the  instructions  for  implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  applicable  codes. 

3.1  INTRODUCTION 

The  power  of  the  ASC  X12  standard  is  in  its  building  block 
concept,  which  standardizes  the  essential  elements  of  business 
transactions.  It  is  analogous  to  a  “standard  bill  of  materials  and 
the  construction  specifications,”  which  gives  the  architect 
flexibility  in  what  can  be  designed  with  standardized  materials  and 
procedures.  The  EDI  system  designer,  like  the  architect,  uses  the 
ASC  X12  standards  to  build  business  transactions  that  are  often 
different  because  of  their  function  and  yet  utilize  the  ASC  X12 
standards.  The  “bill  of  materials  and  the  construction  specification” 
of  ASC  X12  are  the  standards  found  in  the  published  technical 
documentation. 

ASC  X12.3  -  The  Data  Element  Dictionary  specifies  the  data 
elements  used  in  the  construction  of  the  segments  that  comprise 
the  transaction  sets  developed  by  ASC  XI 2. 

ASC  X12.5  -  The  Interchange  Control  Structure  provides  the 
interchange  control  segment  (also  called  an  envelope)  of  a  header 
and  trailer  for  the  electronic  interchange  through  a  data  transmis¬ 
sion;  it  also  provide  a  structure  to  acknowledge  the  receipt  and 
processing  of  the  envelope. 

ASC  X12.6  -  The  Application  Control  Structure  defines  the  basic 
control  structures,  syntax  rules,  and  semantics  of  EDI. 

ASC  X  12.22  -  The  Data  Segment  Directory  provides  the  defini¬ 
tions  and  specifications  of  the  segments  used  in  the  construction 
of  transaction  sets  developed  by  ASC  X12. 

The  DoD  convention  in  Section  3.4  conform  to  the  above  standards 
and  each  transaction  set  is  a  complete  document  to  the  extent 
possible.  For  further  clarification  of  acronyms,  abbreviations,  and 
codes,  refer  to  ASC  X12  published  technical  documentation.  Con¬ 
tact  the  DoD  EDI  Executive  Agent  for  copies  or  the  Data  Inter¬ 
change  Standards  Association,  Inc.,  Suite  355,  1800  Diagonal 
Road,  Alexandria,  VA  22314. 

3.2  CONTROL  SEGMENTS 

In  addition  to  the  communication  control  structure,  the  EDI  structure 
provides  the  standards  user  with  multiple  levels  of  control  to  ensure 
data  integrity.  It  does  so  by  using  header  and  trailer  control  segments 
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designed  to  identify  uniquely  the  start  and  end  of  the  interchange 
functional  groups  and  transaction  sets.  The  relationship  of  these 
control  segments  is  shown  in  Figure  3.2-1.  Control  Segment 
specifications  are  defined  in  Section  3.2.2. 

3.2.1  Description  of  Use 

The  interchange  header  and  trailer  segments  surround  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions: 

•  Define  the  data  element  separators  and  data  segment  ter¬ 
minators 

•  Identify  the  sender  and  receiver 

•  Provide  control  information 

•  Allow  for  authorization  and  security  information. 

The  Interchange  Acknolwedgment  Segment  is  used  to  acknowledge 
one  interchange  header  and  trailer  envelope  where  the  envelope 
surrounds  one  or  more  functional  groups.  (No  acknowledgment  is 
made  for  the  interchange  acknowledgment.) 

The  interchange  control  number  value  in  the  acknowledgment 
(TA1  segment)  is  the  same  as  that  for  the  ISA  segment  that  is 
being  acknowledged.  The  control  number  serves  as  a  link  between 
the  interchange  header  and  trailer  and  the  acknowledgment  of  that 
header  and  trailer. 

The  interchange  acknowledgment  does  not  report  any  status  on  the 
functional  groups  contained  in  the  interchange  and  is  separate 
from  the  communication  system’s  error  procedures. 

The  preparer  of  the  interchange  header  and  trailer  indicates  the 
level  of  acknowledgment  in  Data  Element  113,  Acknowledgment 
Requested.  If  an  acknowledgment  is  requested,  then  the  recipient 
must  return  an  acknowledgment.  If  not  requested,  none  should  be 
given. 

The  interchange  acknowledgment  control  segments  are  placed  after 
the  interchange  header  and  before  the  first  functional  group  or 
before  the  interchange  trailer  if  there  are  no  functional  groups. 

Control  segments  are  standard  for  all  implementation  conventions 
produced  for  the  Department  of  Defense.  Some  codes  associated 
with  individual  data  elements  within  the  control  segments  are 
unique  to  the  individual  transaction  set.  Others,  identify  the  ANSI 
version  and  release  in  which  the  convention  is  written. 
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Segment:  ISA  Interchange  Control  Header 

Purpose:  To  start  and  identify  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

DATA 

OES. _ ELEMENT  NAME _ ATTWtBl/TES 

ISA01  101  Authorization  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Authorization  Information. 

00  No  Authorization  Information  Present  (No  Meaningful  information  in  102) 

ISA02  102  Authorization  Information  M  AN  10/10 

Information  used  for  additional  identification  or  authorization  of  the  sender  or  the 
data  in  the  interchange.  The  type  of  information  is  set  by  the  Authorization 
Information  Qualifier. 

Implementation  Note: 

If  no  authorization  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA03  103  Security  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Security  Information. 

01  Password 

ISA04  104  Security  Information  M  AN  10/10 

This  is  used  for  identifying  the  security  information  about  the  sender  or  the  data 
in  the  interchange.  The  type  of  information  is  set  by  the  Security  Information 
Qualifier. 

Implementation  Note: 

An  agreed  upon  password.  If  no  security  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA05  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

An  agreed  upon  designation  ofDoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

ISA06  106  Interchange  Sender  ID  M  ID  15/15 

Identification  code  published  by  the  sender  for  other  parties  to  use  as  the 
receiver  ID  to  route  data  to  them.  The  sender  always  codes  this  number  in  the 
sender  ID  element. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC )  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 


Mandatory 


ISA07  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
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Code  Value  Implementation  Note: 

An  agreed  upon  designation  ofDoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN). 


Mandatory 


ISA08  107  Interchange  Receiver  ID  M  ID  15/15 

Identification  code  published  by  the  receiver  of  the  data.  When  sending,  it  is 
used  by  the  sender  as  their  sending  ID,  thus  other  parties  sending  to  them  will 
use  this  as  a  receiving  ID  to  route  data  to  them. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  ( DoDAAC )  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


ISA09  108  Interchange  Date  M  DT  6/6 

Date  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  YYMMDD 

ISA  10  109  Interchange  Time  M  TM  4/4 

Time  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  HHMM 

ISA  11  110  Interchange  Control  Standards  Identifier  M  ID  1/1 

Code  to  identify  the  agency  responsible  for  the  control  standard  used  by  the 
message  that  is  enclosed  by  the  interchange  header  and  trailer. 

U  U.S.  EDI  Community  of  ASC  XI 2,  TDCC,  and  UCS 

ISA  12  111  Interchange  Control  Version  Number  M  ID  5/5 

This  version  number  covers  the  interchange  control  segments  and  the  functional 
group  control  segments. 

00301  Draft  Standard  for  Trial  Use  Approved  for  Publication  by  ASC  XI 2  Procedures 
Review  Board  Through  October  1990 

Code  Value  Implementation  Note: 

Version  ID  as  defined  or  agreed  upon  by  the  trading  partners. 

ISA13  112  interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

ISA14  113  Acknowledgment  Requested  M  ID  1/1 

Code  sent  by  the  sender  to  request  an  interchange  acknowledgment. 

0  No  Acknowledgment  Requested 
1  Interchange  Acknowledgment  Requested 

ISA15  114  Test  Indicator  M  ID  1/1 

Code  to  indicate  whether  data  enclosed  by  this  interchange  envelope  is  test  or 
production. 

P  Production  Data 
T  Test  Data 
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Code  Value  Implementation  Note: 

.  Assigned  by  translation  software. 


Mandatory 


ISA16  115  Subelement  Separator  M  AN  l/l 

This  is  a  field  reserved  for  future  expansion  in  separating  data  element 
subgroups.  (In  the  interest  of  a  migration  to  international  standards,  this  should 
be  different  from  the  data  element  separator). 

Implementation  Note: 

Use  character 
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Segment:  GE  Functional  Group  Trailer 

Purpose:  To  indicate  the  end  of  a  functional  group  and  to  provide  control 
information 

Syntax:  The  data  interchange  control  number  (GE02)  in  this  trailer  must  be 

identical  to  the  same  data  element  in  the  associated  Functional  Group 
Header  (GS06). 


Comment:  The  use  of  identical  data  interchange  control  numbers  in  the  associated 
functional  group  header  and  trailer  is  designed  to  maximize  functional 
group  integrity.  The  control  number  is  the  same  as  that  used  in  the 
corresponding  header. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

KEF  OAT* 

PES.  ELEMENT  NAME _ ATTWOTES 

GE01  97  Number  of  Transaction  Sets  Included  M  NO  1/6 

Total  number  of  transaction  sets  included  in  the  functional  group  or  interchange 
(transmission)  group  terminated  by  the  trailer  containing  this  data  element. 

Implementation  Note: 

Assigned  by  translation  software. 

GE02  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  control  number  of  the  preceding 
GS06  control  number. 
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EXAMPLE  ■  FUNCTIONAL  ACKNOWLEDGMENT  TRANSACTION  SET  (997) 


ASCX12  EDI  FORMAT  DEEPflUOM 


ST*997*0001  N/L 


THIS  IS  A  997  FUNCTIONAL 
ACKNOWLEDGMENT  TRANSACTION  SET 
WITH  A  CONTROL  NUMBER  OF  0001. 


AK1*IN*12345  N/L 


A  FUNCTIONAL  ACKNOWLEDGMENT  OF  AN 
810  INVOICE  WITH  A  GROUP  CONTROL 
NUMBER  OF  12345. 


AK2*810*000006  N/L 


ACKNOWLEDGING  810  TRANSACTION  WITH 
CONTROL  NUMBER  000006. 


AK3*PER*6**1  N/L 


INDICATES  UNRECOGNIZED  SEGMENT  ID 
IN  THE  6TH  SEGMENT,  PER. 


AK4*1**6*12X  N/L 


INDICATES  PER01,  DATA  ELEMENT  1 
CONTAINS  ILLEGAL  CHARACTER  "X". 


AK5*R*5  N/L 


TRANSACTION  REJECTED  BECAUSE  ONE 
OR  MORE  SEGMENTS  IN  ERROR. 


AK9*R*1*33*32  N/L 


SINGLE  TRANSACTION  REJECTED;  32  OF  33 
RECEIVED  ACCEPTED. 


SE*8*0001  N/L 


THE  TRANSACTION  SET  HAS  8  SEGMENTS 
AND  THE  CONTROL  NUMBER  IS  0001. 


NOTE:  ALL  NUMBERS  ARE  NOTIONAL  AND  USED  FOR  ILLUSTRATION  PURPOSES  ONLY. 
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997  Functional  Acknowledgment 

This  standard  provides  the  format  and  establishes  the  data  contents  of  a 
functional  acknowledgment  transaction  set.  The  purpose  of  this  standard  is 
to  define  the  control  structures  for  a  set  of  acknowledgments  to  indicate  the 
results  of  the  syntactical  analysis  of  the  electronically  encoded  documents. 
The  encoded  documents  are  the  transaction  sets,  which  are  grouped  in 
functional  groups,  used  in  defining  transactions  for  business  data 
interchange.  This  standard  does  not  cover  the  semantic  meaning  of  the 
information  encoded  in  the  transaction  sets. 


PAGE*  POS.» 
2  010 

3  020 


4  030 


5  040 

7  050 

8  060 

9  070 

11  080 


Table  1 


SEG.  ID  NAME 

REQ.  DES. 

MAX  USE 

LOOP  REPEAT 

ST  Transaction  Set  Header 

M 

1 

AK1  Functional  Group  Response  Header 

pim 

1 

LOOP  IP  -  AK2 

>1 

AK2  Transaction  Set  Response  Header 

o 

1 

LOOP  ID « AK3 

»1 

AK3  Data  Segment  Note 

0 

1 

AK4  Data  Element  Note 

O 

99 

AK5  T ransaction  Set  Response  T railer 

M 

1 

AK9  Functional  Group  Response  Trailer 

M 

1 

SE  Transaction  Set  Trailer 

M 

1 
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Optional 


Segment:  AK3  Data  Segment  Note 
Level:  Header 
Loop:  AK3  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 


ANSI  ASC  X12  VERSION/RELEASE  00301  ODOD_ 


Purpose:  To  report  errors  in  a  data  segment  and  to  identify  the  location  of  the  data 
segment. 


Mandatory 


Mandatory 


Optional 


Optional 


Optional 


Optional 


Optional 


_ Data  Element  Summary _ 

REF.  DATA 

PES.  ELEMENT  NAME _ ATTRWIfTES 

AK301  721  Segment  ID  Code  M  ID  2/3 

Code  defining  the  segment  ID  of  the  data  segment  in  error.  See  Appendix  A  - 
Number  77. 

Implementation  Note: 

Use  the  segment  ID  as  it  appears  in  the  ASC  XI2  Data  Segment  Directory,  e  g.,  REF,  PER,  N],  etc. 

AK302  719  Segment  Position  in  Transaction  Set  M  NO  1/6 

The  numerical  count  position  of  this  data  segment  from  the  start  of  the 
transaction  set:  the  transaction  set  header  is  count  position  1 . 

Implementation  Note: 

e  g.,  1,  2,  3,  etc. 

AK303  447  Loop  Identifier  Code  O  ID  1/4 

Code  identifying  a  loop  within  the  transaction  set  which  is  bounded  by  the  related 
LS  and  LE  segments  (corresponding  LS  and  LE  segments  must  have  the  same 
value  for  loop  identifier).  (Note:  The  loop  ID  number  given  on  the  transaction  set 
diagram  is  recommended  as  the  value  for  this  data  element  in  segments  LS  and 
LE.) 

Implementation  Note: 

e  g.,  Nl,  POl,  etc. 

AK304  720  Segment  Syntax  Error  Code  O  ID  1/3 

Code  indicating  error  found  based  on  the  syntax  editing  of  a  segment 

Implementation  Note: 

Use  any  code. 

AK305  720  Segment  Syntax  Error  Code  O  ID  1/3 

Code  indicating  error  found  based  on  the  syntax  editing  of  a  segment 

Implementation  Note: 

Use  any  code. 

AK306  720  Segment  Syntax  Error  Code  O  ID  1/3 

Code  indicating  error  found  based  on  the  syntax  editing  of  a  segment 

Implementation  Note: 

Use  any  code. 

AK307  720  Segment  Syntax  Error  Code  O  ID  1/3 

Code  indicating  error  found  based  on  the  syntax  editing  of  a  segment 
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Optional 


Segment:  AK4  Data  Element  Note 
Level:  Header 
Loop:  AK3 
Usage:  Optional 
Max  Use:  99 

Purpose:  To  report  errors  in  a  data  element  and  to  identify  the  location  of  the  data 
element. 


Mandatory 


Optional 


Mandatory 


Optional 


_ Data  Element  Summary _ 

KEF.  DATA 

DES. _ ELEMENT  NAME _ ATTRIBUTES _ 

AK401  722  Element  Position  in  Segment  M  NO  1/2 

This  is  used  to  indicate  the  relative  position  of  the  data  element  in  error  in  this 
data  segment.  The  count  starts  with  1  for  the  data  element  immediately  following 
the  segment  ID.  This  value  is  0  for  an  error  in  the  segment  ID. 

Implementation  Note: 

AK4  =  0.AK401  =  1.AK402  =  2.  etc. 

AK402  725  Data  Element  Reference  Number  O  NO  1/4 

Reference  number  used  to  locate  the  Data  Element  Dictionary. 

Implementation  Note: 

AK401  =  722,  AK402  =  725,  etc. 

AK403  723  Data  Element  Syntax  Error  Code  M  ID  1/3 

Code  indicating  the  error  found  after  syntax  edits  of  a  data  element. 

Implementation  Note: 

Use  any  code. 

AK404  724  Copy  of  Bad  Data  Element  O  AN  1/99 

This  is  a  copy  of  the  data  element  in  error. 
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997  •  FUNCTIONAL  ACKNOWLEDGEMENT 
AK5  •  TRANSACTION  SET  RESPONSE  TRAILER 


Segment:  AK5  Transaction  Set  Response  Trailer 
Level:  Header 


Mandatory 


Loop:  AK2 
Usage:  Mandatory 
Max  Use:  1 

Purpose:  To  acknowledge  acceptance  or  rejection  and  to  report  errors  in  a 
transaction  set. 


Mandatory 


Optional 


Optional 


Optional 


Optional 


Optional 


_ Data  Element  Summary _ 

AEF  DATA 

DCS. _ CLEMENT  NAME _ ATTRIBUTES 

AK501  717  Transaction  Set  Acknowledgment  Code  M  ID  1/1 

Code  indicating  accept  or  reject  condition  based  on  the  syntax  editing  of  the 
transaction  set. 

Implementation  Note: 

Use  any  appropriate  code. 

AK502  718  Transaction  Set  Syntax  Error  Code  O  ID  1/3 

Code  indicating  error  found  based  on  the  syntax  editing  of  a  transaction  set. 

Implementation  Note: 

Use  any  code. 

AK503  718  Transaction  Set  Syntax  Error  Code  O  ID  1/3 

Code  indicating  error  found  based  on  the  syntax  editing  of  a  transaction  set. 

Implementation  Note: 

Use  any  code. 

AK504  718  Transaction  Set  Syntax  Error  Code  O  ID  1/3 

Code  indicating  error  found  based  on  the  syntax  editing  of  a  transaction  set. 

Implementation  Note: 

Use  any  code. 

AK505  718  Transaction  Set  Syntax  Error  Code  O  ID  1/3 

Code  indicating  error  found  based  on  the  syntax  editing  of  a  transaction  set. 

Implementation  Note: 

Use  any  code 

AK506  718  Transaction  Set  Syntax  Error  Code  O  ID  1/3 

Code  indicating  error  found  based  on  the  syntax  editing  of  a  transaction  set. 

Implementation  Note: 

Use  any  rode. 
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ANSI  ASC  X12  VERSION/RELEASE  00301  OPOD_ 

Code  indicating  error  found  based  on  the  syntax  editing  of  the  functional  group 
header  and/or  trailer. 

Implementation  Note: 

Use  any  code. 


Optional 


AK909  716  Functional  Group  Syntax  Error  Code  O  ID  1/3 

Code  indicating  error  found  based  on  the  syntax  editing  of  the  functional  group 
header  and/or  trailer. 


Implementation  Note: 

Use  any  code. 


DA04  •  JANUARY  29  1993 


10 


997  •  FUNCTIONAL  ACKNOWLEDGEMENT 
SE  •  TRANSACTION  SET  TRAILER 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTIONS 


ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 


11 


0A04.  JANUARY  29  1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


BASELINE  AS  OF:  JANUARY  29, 1993 


4.0  ASC  X  12  FORMS 


In  this  chapter,  applicable  ASC  X12  forms  are  presented. 


I  0  1 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


X1MMA  MPORMATBN  MANUAL 


VIII  -  FORMS,  FORMS,  FORMS 


ASC  X12  Wot*  Roquoot  Form 

ASC  X12  New  Projoct  Proposal  Form 

ASC  X12  Now  Transaction  Sot  Dovotopmont  Form 

Form  for  Now  or  Rovlsod  Appondbt  A  Codo  Sourco  Roforonco 

Oooumom  Proportion  lor  irtoiprotations.  (kridoUnoo  and  Control  Standards 

Sompto  Tranomltol  Form 

ASC  X12  Balot  Common!  Rooponao  Lott  or  Form*! 

ASC  X12  Standards  Ordor  Form 


PALL  1000 


VIII- 1 


BASEUNE  AS  OF:  JANUARY  20, 1003 


4.0.3 


Ae».  S/10/90 

OATE  SUBMITTED 


-  ASCX12 

WORK  REQUEST  FORM 


DM  NUMBER _ 

(Secretariat  Only) 


"all  REC IESTS  MUST  BE  TYPED  Of  printed  legibly  m  black  ink.  Compiet#  both  sides. 


1.  TO  USE  THIS  FOSM  FOB  SUPPORTWG  OATA  MAMTENANCS  FOR  A  NEW  WAFT  STANDARD  On  X12  INTERPRETATION.  M  *1 
requirement  on  ONE  term.  UM  attachments  at  necessary.  Ust  ftrsl  a*  new  women*.  *ren  •*  new  data  alsmonts/oodss/eods  aouresa. 
Than  Bat  reviwone  to  aetaOng  aaQmanti  and  data  atamanw/coPaa/ooda  source*.  Then  Bet  any  other»  (eg.,  X12.5.  X12.6). 

1  TOUSETWSFORMTOREOUEST  ACHANGETO  AN  EXIETPfG  STANOAAO,  uee  a  eeparaae  Asquaat  Form  to  Bat  aN  changas  tor 

one  Iran— clion  »et  owe  segment.  aw  control  Nwcw,  or  ore  date  dement  A*  McHom  must  be  eomptatad.  Aitartonoma  may  MuMd 
for  continuation  and  should  be  numbered. 


3.  TO  USE  TMS  FOAM  TO  REQUEST  A  PROPOSED  NEW  X12  PROJECT,  complete  Section  A  Provide  a  purpooe/oeopo  and  describe  ony 
new  features  involved  in  Section  B.  Provlda  a  description  off*  budnaoo  need  end  juotMcallon  tor  tie  now  protect  In  Socdon  C/Port  S.  The 
WortiWoquoctwiS  bo  torwerdod  toon  tppwpffetc  XU  cuboommlbcc  tar  anolyoic  and  properaSon  of  o  prefect  pwpooaf. 

Circle  One:  (i)  New  Standard  Supporting  Data  Maintenance  (use  sttschments) 

(2)  Existing  Standard  Maintenance  Request  (see  Section  0) 

(3)  Request  tar  New  X12  Project 

Acronyme/abbreviadone  earwot  bo  added  to  **e  etandorde.  btduoby  tportSr  tom*  meat  bo  doariy  oaptdnod.  Provide  AppandbiAooda 

- —  -  -  -  *  -  - -  -  *  —  -  -  -  -  -  ^  —  fcw_fc-  -  -«»•-*  ■  —  l  —  *  —  ^  a^^AA  Miia  WajtMk  i«aa  *njyyuA  Igu 

•OUM  I9WM6M  IOf  M  IIWMIy  puMMM  OOM  MU  QMN.  MOfflpitW  fPfTIM  Or  TCN  WWI  nOOqUMO  HqHMWI  *Or  VW  cnmgi  rvqUMM 
wil  bo  returned  to  Sia  aubminor. 

A.  SUBMITTER  INFORMATION- 

Submitter  Name  _ 

Company  _ _________ _ 

Address  _ 

Address/ZIP  _ 

Phone  _ _ _ 


Indicate  the  X12  subcommittee  or  task  group  whose  position  is  represented  here. 

I  declare  that  this  represents  the  official  position  ot  X12  WORK  GROUP: _ 

established  at  the  meeting  dated _ . 

B.  PROPOSED  wbRK:  List  the  specific  changes  to  the  standards  betnQ  requested.  Give  the  names  and 
associated  kJentMere  ol  the  standards,  segments,  data  elements  and  codes  affected. 


4A4 


BASELINE  AS  OF:  JANUARY  2t,  1**3 


DEPAOT1MNT  OP  MFBMC 
DIUPT  MPLEUeiTATWN  OOMWmON 


Pag*  Two 

k.  REASON  FOR  CHANGE: 

Parti:  List  th*  varsion/ralaaaa  of  the  standard  you  art  using  or  using  as  a  raiaranca.  Nama  tha  transaction  aat 
that  la  being/ wW  ba  used  that  dictates  tha  requested  changed.  List  affected  segments  and  data  elements,  or 
other  standards.  Provide  only  reference  numbers/ID*. 

Reference  Source  Version  2/Releese _ 

Transaction  Set  Used  _ 

Segment  Affected  _ 

Data  Element  Affected _ 

Other  Standard _ 

Part  II:  Explain  why  you  need  the  proposed  change.  Provide  a  complete  scenario  that  tals  what  the  business 
function,  operation,  or  problem  is  that  wd  be  satisfied  by  a  change  to  the  standard.  The  X12J  Technical 
Assessment  Subcommittee  requires  enough  information  in  this  Part  tl  to  be  able  to  propose  an  aitamata  solution  f 

necessary. 


0.  RAMIFICATIONS:  tf  you  circled  (2)  on  Page  1 .  complete  this  section.  To  ensure  that  a<  ramWaOons  of  your 
proposed  change  are  recorded  and  that  your  request  is  complete,  circle  beta**  al  sections  of  the  standards 
affected  by  the  proposed  change. 


TRANSACTION  SET  Nwm  PurpoM/Seop*  Tim  Now/Commam 

SsamswtPMUw  Rwm.  Oaa.  Mw.Uw 

Loop  Loop  tOucfepo  Wtf  SOQOIOflt 

Won  SopffioM 


SEGMENT 


Cwnmwit 

DATA  ELEMENT  Nwm  Owertpam  Typ. 

Mfl/Mn 

CODE  Add  mda  OatmCod*  IWvtMCodt 

OTHER  (e.g.,  X12J.  X12.6): 

ERRORS  NOTED  IN  THE  STANDARD  (GNe  pegs  no.  and  other  dentifteation): 


mnnftBrr 

DRAFT  MPLEMENTATK3M  CONVENTION 


A*v  4/1/90 


PP  No. _ 

(Secretariat  Only) 


ASC  XI 2 

NEW  PROJECT  PROPOSAL  FORM 

PROCEDURE:  Only  X12  subcommittees  may  us*  this  form  to  register  new  development  activities  as  X12  project 
proposals  (PPs).  Com  plots  all  pages.  PPs  approved  by  the  X12  Procedures  Review  Board  will  be  registered  and 
assigned  a  PP  number  by  DISA,  and  a  Transmittal  Form  w9l  be  issued. 

Date  and  complete  the  form  below.  Type  or  print  legibly  in  black  ink  and  number  all  attachment  pages 
consecutively.  Submit  to  DlSA  prior  to  an  ASC  XI 2  meeting,  or  to  X12J  Technical  Assessment  Subcommittee 
during  the  subcommittee's  agenda  period  at  an  ASC  X12  meeting. 


Date  Submitted: 

Date  Approved  by  Subcommittee: 

Subcommittee  Name: 

Teak  Group  Name/No.: 

Joint  Development  Subcommittee  (H  any): 

Circle  one:  (a)  Transaction  Set  (b)  Guideline  (c)  Other 

Project  Working  Title: 


Official  Delegate(s)  ter  This  Project  To  Be  Named  on  Transmittal  Form: 
Name _ Name _ 

Company _ Company _ 

Address _ Address _ 


Address/21  P _ Address/ZIP 

Telephone _ Telephone 


4.0.S 


BASEUNE  AS  OP:  JANUARY  29, 1993 


D&AftTWOfT  OF  DEFENSE 
DRAFT  MPUMBfrATION  CONVENTION 


A.  PURPOSE  AND  SCOPE  FOR  THE  PROPOSED  W&tK:  Provide a  w5Ws55d  purpose/seope  form* 
proposed  wot*.  See  X12  Design  RiJes  and  Guidelines  for  requirements. 


B.  BACKGROUND;  Provide  deals  that  w<  be  hsipfil  In  reviewing  the  proposal  Who  ere  the  expected  users? 
How  wM  the  standard  be  used?  What  business  functions)  doee  I  serve?.  If  the  proposed  standard  overlaps  the 
functionality  of  an  existing  standard  or  one  In  development,  provide  |ust<lcailot*  If  the  propoeel  la  not  tor  a  new 
standard  or  guideline,  describe  the  protects*  deal  (Use  attachments  IT  neceeaary.) 


L  6THER  STANQARO*  MVOLVCth  N  appMcsble,  Identify  any  other  business  information  standards  thetairs 
simlar/rsiated  to  the  propoaal.  and  name  standards  developers  (e.g.,  ANSI  Accredited  Standards  Commatees) 
whose  actMtlee  may  be  involved  or  affected. 


D.  EXPECTED  COWTENT/OENEfUL  DEBCRlPTION:  (OPTIONAL)  Submtoer  nwy  attach  a  preliminary  drift  ot 
the  proposed  standard  or  other  supporting  documentation.  Discuss  new  segments,  data  elements,  control 
structures,  and  changes  to  XiiS  or  X12.6  that  am  required  or  enddpaud.  (Use  attachments.) 
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FORM  FOR  NEW  OR  REVISED 
APPENDIX  A  CODE  SOURCE  REFERENCE 

INSTRUCTIONS:  Complete  this  form  whenever  a  new  data  element  or  data  element  cod*  it  requested  to  be 
added  which  references  a  code  list  published  by  an  external  (non-Xl2)  organization.  Use  one  form  for  each  new 
reference.  This  form  may  be  used  to  revise  current  references:  fill  out  the  appropriate  areas  below. 


CIRCLE  ONE.  COMPLETE  AS  APPROPRIATE: 

(1)  NEW  REFERENCE 

(2)  REVISED  REFERENCE.  Current  reference  number/name 


REFERENCE  TITLE:  If  there  is  only  one  source  for  codes  for  the  data  element,  the  title  should  be  the  same  as  the 
data  element  name.  If  there  are  multiple  codes  referencing  external  code  sources  for  the  same  data  element,  title 
should  approximate  the  code  definition. 

REFERENCE  TITLE: 


DATA  ELEMENTS  USED  IN:  Give  the  data  element  reference  number  and  name  which  directs  the  user  to  this 
Appendix  A  code  source  reference.  Give  the  code  ID  (V  assigned)  if  this  Is  tar  a  specific  code  of  the  data  element 

USED  IN:  DE  No. _ .  Code  ID _ 


SOURCE:  Provide  the  name  of  the  publication  which  contains  the  codes  referenced. 

PUBLISHED  IN: 

AVAILABLE  FROM:  Give  the  publisher,  or  other  contact  from  whom  the  user  can  obtain  the  document 

Name/Attn  of  _ _ 

Company _ _ 

Address  _ _ 

Address  _ _ 

Address /ZIP _ 

ABSTRACT:  Briefly  describe  the  publication.  Its  purpose,  and  indicate  what  codes  It  contains. 
ABSTRACT: 
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DOCUMENT  PREPARATION  FOR 
INTERPRETATIONS,  GUIDELINES  AND  CONTROL  STANDARDS 


That*  instruction*  are  provided  to  tssJsl  developer*  of  mttrprsutions.  guidelines  and  control  structure  which  are 
not  transaction  sats  (for  transaction  ssts  usa  th#  Maw  Transaction  Sat  Development  Form). 

GENERAL:  OISA  provides  tide  paga  and  front  mattar  for  publications  and  copyedlts  th*  documant  according  to 
OfSA  housa  style. 

REVISIONS:  If  th*  documant  is  a  revision  of  a  previously  publiahad  interpretation,  guidalina  or  standard,  provide  a 
summary  of  th*  changas  to  th*  original  that  are  containad  in  th*  documera. 

I  INTERPRETATIONS 

A  formal  interpretation  of  an  X12™  Standard  is  considered  part  of  th*  body  of  standards  when  it  Is  approved  for 
publication.  Tha  Intarpretation  draft  should  stata  tha  Issua  prasantad  by  tha  requaator.  stata  tha  proposed 
interpretation.  and  show  as  attachmants  any  Work  Raquasts  that  may  ba  nacasaary  to  aifacttha  Intarpretation 
within  tha  subject  standard.  Th*  draft  Intarpretation  la  procassad  Ik*  any  othar  subcommltt**  documant 

II  GUIDELINES 

For  publication  purposes,  guidelines  are  treated  Ik*  a  journal  artid*.  Basic  requirements  are  glvan  baiow. 

ABSTRACT:  Thto  is  a  precise  summary  of  thePurposa/Scop*  (see  below),  and  may  be  identical  to  ft  ft  that  is  brief 
(two  paragraphs):  otherwise  summarize  tha  purpoee/scop*.  ft  should  contain  enough  Information  about  th* 
documant  to  anabl*  a  reader  datermina  what  tha  guidalina  is  intended  to  accomplish  wfthin  an  EDI  environment. 

PURPOSE  AND  SCOPE:  This  statement  must  Indicate  purpoa*  of  th*  guidalina.  *.g.,  the  buainaas  function  or 
operation  addressed.  Scope  and  any  spadftc  imitations  of  scope  shodd  be  dallnad. 

BODY  OF  TEXT:  This  may  ba  a  number  of  subsections  logicaBy  organized.  Provide  sections  tor  foreword, 
introduction,  definition  of  term*  and  concepts,  references  and  related  standards,  methodology,  specification*, 
requirements,  discussion,  and  conclusions,  as  appropriate  to  th*  subject 

ART  AND  GRAPHICS:  Graphics  or  artwork  necessary  to  Dustrat*  th*  documant  are  encouraged.  Provide 
camera-ready  copy  if  these  are  not  already  prepared  and  delivered  on  a  WP  diskette  to  D1SA. 

FOREWORD.  FOOTNOTES.  APPENDICES:  These  may  ba  used  for  purpoaas  of  clarity.  ■ustration.  or  ganerM 
information,  not  as  'part  of  th*  guideline.'  A  statement  Indicating  tha  material  Is  tor  information  purposes  only  and 
not  part  of  th*  guideline  shaft  tppeer  at  the  beginning  of  a  foreword  or  appendk. 

III  CONTROL  STRUCTURES  AND  OTHER  STANDARDS 

For  publication  purpose*,  these  documents  are  treat sd  Iks  guid alines  (as*  Section  II  above).  Th*  requirements  are 
th*  same,  with  th*  addtton  of  tha  foacwtng: 

NEW  SEGMENTS  AND  OATA  ELEMENTS:  These  may  ba  defined  within  th*  tsxr,  however,  sine*  they  represent 
changes  to  X  12.22  and  X12.3,  they  shotid  ba  specified  on  a  Work  Request  Form  attached  to  the  draft 

RELATED  X12™  STANDARDS  AND  OTHER  REFERENCES:  These  shal  ba  Identified  In  a  section  wfthto  th*  text 


BASELINE  AS  OF:  JANUARY  29, 1993 
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Pago  Two 

FORMAT:  This  DraR  Standard  tor  Trial  Use  contains  the  format  and  establishes  the  data  contents  of  the 

_ Tranaacdon  Sat  ( _ )  tor  uae  wthin  the  context  of  an  Electronic  Data  interchange  (EDf) 

environment.  The  transaction  set  (can  be  uaad  to...)* 


6.  RURROil  AND  The  statement  met  Indicats  the  fii  ranga  of  capaONbaa  of  the  tranaacdon  set.  and 

whothaaandara/raeafcanara.  Explain  tha  buainaaa  function  or  oparadon  that  ia  addraaaad.  Fdo*ASCXi2 
DaaignRMaa  and  GuMaNnaa  and  uaadda  format 

FORMAT:  This  standard  provides  tha  format  and  eatabliohes  tha  data  eontanta  of  tha _ Tranaacdon 

Sat  wthin  tha  context  of  an  Electronic  Data  interchange  (EDI)  environment.  The  tranaacdon  set  (can  ba  uaad  to  ..)* 


D.  TRANSACTION  s£+  TA»U(S)  ^or  each  table  provtte  the  toiowtng  totormattoa  FoAmaTT 

TABLE  X 


POSITION  SEGMENT 

UflLt _ ID  TITLE _ 

010  ST  Transaction  Sat  Header 

020  BB  Beginning  Segment  For 

etc. 


REQ.  MAX. 
DBS* „  BSE. 
M  1 

M  1 


LOOP  REPEAT  NOTE 


_ BEL. 

Mote  1 
Comment  i 


Note  1:  The  la  a  note.  NOTES  art  port  of  tha  standard  (numbered). 

Comment  A:  Thi*  m  a  comment  COMMENTS  are  not  part  ofthe  standard  Oattarad). 


£.  APPENDIX  EXAMPLES  Exampias  are  uaad  to  last  the  mart  of  dm  proposed  tranaacdon  and  to  aagSTi  to 
users.  At  team  one  example  ia  mandatory.  No  racogntzabfe  proper  names  may  be  uaad  In  any  example. 

FIGURE  1:  (Optional)  Use  a  sample  paper  document  using  mock  dam.  If  uaad.  data  must  be  accurately  mapped 
to  Figure  2.  Original  graphics  mutf  bo  adachad  (8-i/fccif)  so  they  emi  be  copied. 

FIGURE  2  (or  EXAMPLE):  Tie  tttaRgwa  and  provido  a  Business  Scenario  to  attain  to  tha  reader  what  la  going 
on  in  the  example.  Add  the  note:  Tn  Wo  example  tha  asterisk  (•)  represents  the  data  eiemont  separator  art  the 
m/l  characters  represent  tha  segment  terminator.*  Prsoort  EDI  transmission  data  art  ftamawdng  in  two  coUrsm. 
Mde-by-side.  22  or 232  codas  are  dtooourogod,  since  their  uaohJnoss  In  mt  explanatory  example  lard.  FORMAT: 

BUSINESS  SCENARIO:  in  this  tranaacdon  sat  tha  sender  is  XV2  Ratal  Carter  art  tha  receiver  la  their  supplier. 
Fantastic  Products  Manufacturing  lnc....stc 

EB1  TRANSMISSION  PATA _ (transaction  set  purpose)  data 

ST*SXX*0005  N/L  Begin  Transaction  Set  SXX;  control 

No.  0005 

BB*0i*79t00*  N/L  Original  Transmission;  Ref.  No. 

79800 

etc. 


4.0.10 
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DEPARTMENT  OF  DEFENSE 
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Rw.  3/10/90 

DM  Numb* _ 

(Secretariat  Only) 

Document  No. _ 

(Developer  Obtains  from  DISA) 


ASC  XI 2 

NEW  TRANSACTION  SET  DEVELOPMENT  FORM 


INSTRUCTIONS:  Use  this  form  to  submit  a  draft  transaction  set  for  review  by  X12J  Technical  Assessment  untl  I  Is 
text  processed  by  DISA.  Use  a  new  Transaction  Set  Development  Form  whenever  revisions  are  proposed  and  a 
text  He  has  not  yet  been  prepared  by  DISA. 

ATTACHMENTS:  Attach  M  pages;  use  this  form  as  the  first  Folow  these  Instructions  for  preparing  materials. 

The  submktsr  must  obtain  a  document  number  assignment  from  DISA.  Post  R  to  this  form  (above). 

Attach  a  Ust  of  Revfelora  » the  draft  was  previously  reviewed  by  XI 2J  or  V  this  la  a  revised/redesigned 
transaction  sat  sttndard  requiring  X12  belOL 

Use  ONE  Work  Request  Form  to  list  al  supporting  data  maintenance  for  the  transaction  a*  and  attach  t 
to  this  form.  Propoae  new  or  revised  codes  for  OE 143  and  DE  «79  at  a  minimum,  V  required. 

A  Transmittal  Form  must  accompany  this  document  when  R  la  submated  to  DISA  for  distribtfion. 

Use  the  most  recent  X12™  Standards  Development  Workbook  to  check  your  document  for  accuracy. 

A.  iUBMITTER  INFORMATION 

Submitter  Name  _ _ 

Company  _ 

Address  _ 

Addresa/ZlP  _ 


indicate  the  Xt2  subcommRtee  or  task  group  whose  position  is  represented  here. 

i  declare  that  this  represents  the  official  position  of  X12  WORK  GROUP: _ 

established  at  the  meeting  dated _ . 


I.  ABSTRACT  The  Abstract  is  registered  wkh  the  American  National  Standards  Institute.  It  is  a  precise  summary 
of  the  Purpoee/Scope  (see  Section  C  below).  It  may  be  Identical  to  the  Purpoee/Scope  V  that  is  brief  (two 
paragraphs),  otherwise  summarize  the  purpoee/scope.  R  shotid  contain  enough  Information  about  the  standard 
to  enable  a  potential  user  determine  what  equNalent  paper  transaction  R  represents  or  what  the  standard  is 
intended  to  do  Folow  the  format  on  page  two. 
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SAMPLE  TRANSMITTAL  FORM 


Am.  9/10/90 


Initialized 

KEY  DATE:  February  18, 1990 

DELEGATE'S  NAME 
RESPONSIBLE  SUBCOMMITTEE/TG# 

TRANSACTION  SET/GUIOEUNE  TITLE 

BALLOT  Document  No. 

Current  Document  No. 

Previous  Document  No. 

Project  Proposal  No. 

Associated  WR/DM  No. 


John  Doe 

ASC  XI 2Q  XX  Subcommittee/TG4 
X12J0C  ABC/XYZ  TRANSACTION  SET  (SXX) 


ASC  X12Q/90-051 
ASCX120/90-004 
PP-989 
DM  012-190 


PROJECT  PROPOSAL 

PP  Review  by  X12J  (DATE)  2/7/90 

PRB  Approves  PP  (DATE)  2/9/90 


DEVELOPMENT  PHASE:  Project  proposal  approval  through  approval  tor  X12  vote. 


Document  Submitted  tor  DISA  Tax!  Processing  (DATE) 

Subcommittee  Approves  Draft  tor  Review  by  X12J,  Tech  Assessment  PATE) 

X12J  Tech  Assessment  Review  (DATE) 

PRB  Approves  Document  for  X12  Vote  PATE) 


ORIGINAL  BALLOT  DATA  piSA): 


Ballot  Closed  Date 

Tally/Comments  Sent  to  Chair/Delegates 
Tally  Stats  (Number  and  Percent) 

_ Ballots  Maled  (100%) 

_ Ballou  Returned  ( _ %) 

_ Approved  ( _ .%) 

_ Appw/Comment  ( _ %) 

_ Disapproved  ( _ %) 

_ Abstained  ( _ ,%) 


PATE) 

PATE) 
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Pag*  Two 


COMMENT  RESOLUTION  PHASE:  Saa  Sections  A,  B  and  C.  If  the  subcommlna*  at  any  tim#  decides  to  rebalkX 
tha  document  PRB  approval  It  raqulrad  and  rasponsa  lattart  ara  not  nacasaary. 

A.  COMMENT  RESPONSE  LETTERS:  An  Open  Forum  must  be  schediled  at  the  next  Xt2  meeting  foflowing  the 
baloc  doting  data.  AM  thoaa  who  commented  receive  a  comment  rasponsa  latter  from  tha  developing 
subcommittee.  DISA  record*  this  procast  and  handlat  tha  mallng. 

Open  Forum  Data  (DATE) _ 

Responae  Lattart  Mated  Out  by  DISA  (DATE) _ 

Rebuttal  Period  (30  days)  Ooeee  (DATE) _ 


ADJUSTED  BALLOT  DATA  (DISA): 

90-Oay  Response  Review  Ooaad  Data  (DATE) 

Taly/Commenu  Sant  to  Chalr/Dalagataa  (DATE) 

Taly  Stats  (Number  and  Parcant) 

_ Balots  Malad  (100%) 

_ Balou  Returned  ( _ %) 

_ Approved  ( _ %) 

_ Appw/Commant  ( _ %) 

Disapproved  ( _ %) 

_ Abtumad  ( _ %) 


B.  SUBSTANTIVE  REVISION:  If  batot  comments  resift  In  substantive  revisions  to  tha  documenL  these  ara 
reviewed  by  X12J  and  procaaaad  by  OISA  The  revised  document  it  submitted  to  X12  voters  for  a  904ay  review 
period.  DISA  records  this  procass/han&es  mallng.  Subcommittee*  should  conduct  30-day  reviews  for  response 
lettars/revltad  documents  concurrently. 


Subcommittee  Approval  of  Revisions  (DATE) 

X12J  Review  of  Revisions  (DATE) 

DISA  Malt  Revised  Document  (DATE) 

Substantive  Revision  90-Day  Review  doses  (DATE) 


ADJUSTED  BALLOT  DATA  (DISA): 

90-Day  Substantive  Change  Review  dosed  Date  (DATE) 

Taly /Comments  Sent  to  Chair /Delegates  (DATE) 

Taly  Stats  (Number  and  Parcant) 

_ Balou  Mated  (100%) 

_ Balou  Returned  ( _ %) 

_ Approved  ( _ %) 

_ Appw/Comment  ( _ %) 

_ Disapproved  ( _ %) 

_ Absulned  ( _ %) 
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C.  CONTINUING  OBJECTIONS.  If  there  are  continuing  disapprovals  after  the  30-day  review  period,  the 
document /disapprovals/responses/continuing  objections  are  mated  to  X12  members  who  originally  cast  a  ballot, 
for  another  30-day  review,  to  give  them  an  opportunity  to  change  their  vote. 

Continuing  Objections  Maled  to  Chair /Delegate  by  DISA 
DISA  Mats  Documents 
30-Day  Review  Closes 


FINAL  ADJUSTED  TALLY  (DISA):  Whenever  any  disapprovals  are  withdrawn,  a  letter  to  this  effect  must  be 
received  in  writing  by  DISA 

Final  Tally  Results  Sent  to  Chair /Delegate  (DATE) _ 

30-Day  Review  Stats  (Adjusted  Tally) 

_ Ballots  Maled  (100%) 

_ Ballou  Returned  ( _ %) 

_ Approved  ( _ %) 

_ Appw/Comment  ( _ %) 

_ Disapproved  ( _ %) 

_ Abstained  ( _ %) 


PRB  APPROVAL  PHASE:  After  the  comment  resolution  period,  the  subcommittee  votes  to  submit  the  document 
to  the  PRB  for  approval  to  publish. 

Subcommittee  Votes  to  Release  to  PRB 
PRB  Approves  Publication 


FOR  DRAFT  STANDARDS  FOR  TRIAL  USE: 
VERSION/RELEASE/SUBRELEASE  ID  COOE  ASSIGNED: 


PATE) 

PATE) 


PATE) 

PATE) 

PATE) 
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TRANSMITTAL  FORM  INSTRUCTIONS: 

GENERAL:  Thl*  Tranamloat  Form  it  a  TURNAROUND  DOCUMENT  which  record*  the  hfatory/eurrent  status  of  a 
project  document.  It  la  uaed  to  exchange  information  between  the  Secretariat  and  the  eommiBaaa  of  X12. 
Information  la  cumtiathe  (add  on).  Thlc  Ibrm  la  attached  to  tha  documant  whenever!  la  iaauad  lor  dlatributlon  (K  la 
mandatory  for  automating  documanta  to  DfSA.  X12J  Technical  Aaaaaamant  and  the  PRB).  Document  control 
numbars  ara  atB  raqulrad  on  each  documert,  and  now  numbara  ara  raqulrad  whenever  I  la  ravtaed. 

KEY  DATE:  TNa  t>  uaad  to  Idantty  tha  lataat  varaton  of  tha  documant  (data  aaaodatad  wth  tha  currant  tranamlBaf 
tarmupdata). 


DELEGATE:  Each  eubcommtt—  dailgnataa  an  IndMdual  (delegate)  from  tha  group  raaponcM*  lortha  protact 
Tha  Secretariat  mgat  ba  Informed  *  tha  dalagM*  changaa. 

INITIATION:  Primary  data  It  recorded  by  OfSA  on  tha  MtMzad  form  after  tha  project  propoaai  la  approved  by  tha 
PRB.  Tha  tufacommttee  chair  and  dalagatafa)  recede  tha  indafeed  Tranamfuaf  Form  from  DfSA.  thereafter,  they 
ara  raaponafeia  for  recording  tha  appropriate  auboommfttaa  approval  data*.  Tha  chalr/dalagaia  W  receive  a  copy 
of  tha  updated  tranemfttaf  term  whenever  I  la  ravtcad  by  DfSA. 

UPDATING:  At  each  appropriate  atap.  DfSA  wl  POST  ttaah  data  to  tha  form.  ADD  tha  newt  appropriate  blat*a  to 
tha  form,  and  SEND!  to  th*  aubcommKtaa  chafr/datagata  at  aachatatua  change.  The  dalagata  muat  POST  tha 
term  wth  fraah  data  at  aach  atatua  change  lor  which  tha  aubcommttaa  la  raaponaUa  and  SEND  l  wth  tha 
appropriate  documant  to  the  Secretarial. 
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\SC  XI 2  BALLOT  COMMENT 
1ESPONSE  LETTER  FORMAT 


(UMERAL  MFORMATION 

AFTER  AN  XII  BALLOT,  THE  RESPONSIBLE  SUSOOMISTTEE  (OR  ITE  OEMNATED  TASK  GROUP)  MUST  fMpand  h  ■rtdnfl  •>  of 
AmriwiI  nwi  ThaOrpogodnniProcaNMt  mwuA(ONI)i— odiaiyouaia aouoquaodniMpondNdNM  momboraaNe 
apprauad  witi  aomnoni.  but  Vpeoiy  al  aommonon  aio  toopondod  lo.  Tha  OFM  Oana  ME  oonunam  woponBaa  wmt bo  ooortNaaa d 
■MiMEAMimMCMr. 


Thor*  art  too  rotponoo  NSar  tooiMtt  (ram  ohfeh  b  choooo:  ogonortcNsar  nhNhoMbooat dloolaoaMnon»»,andaHMNdualaod 
raaponio  id  —eh  oommoroor.  3m  random  Mow  and  No  Mmm. 

OPTION  1:  QENERK  UTTER  (MASTER  UTTER)  TO  ALL  OOMMENTORS 

YoumrpMMmliMANiMBSMmnm.  E»ury eonunom wawd muO bo ropraduood h y»M NSar.  For oocti common: 
rtwaMW op«on. you mM roup >» wn—iMiwWifc rrt igapond  to  dnm  M A roup.  Sooty owmhor ddlSaappra  tod  natal  bo 


OPTION  X;  MOMOUAL  UTTER  TO  EACH  COMMVfTOR 

You  may  propat*  cno  Noar  Nr  aadt  oommoraor  It  you  ohaoM  Ida  opdan,  you  noadnatnpaol  9*  origM  common!  proddad  on  d«o  baSai 
Fodow  dm  uaual  buainott  N(Mr  atyN  and  tia  ganarat  Naauedono  baNw.  Story  mambartmt  MMppnwmd  natal  bo  wapondadlB. 


MTRUCTMNS 

SIEFl:  Plan  H  print  dm  drat  page  at  your  NMt(a)  on  ASCXIENsartmad.  d  you  Abut  haw  NSnrtmad.  you  can  obmin  nemo  dam  dm 

STEFS:  Cal  dm  SoenwmNi  Nr  odooumontoonaol  number.  Thm  number  natal  appear  in  dm  mpar  right  oomar  at  dm  Not  pago  at  dm  Moor. 
*  you  tend  on  iwaunt  wIrBrt  NtHr  N  oodi  oommgnmr.bwdBomitoniooimolnumbarBBBlpneri  Nr  dm  NailtOaraM  bo  Ndowod  by  on  VI* 
(a*.  ASC  X12F/TON1O-130A).  dm  ooeand  by  of  (a.*..  ARC  XI  tffflSMO>120S).  e*. 

STEFS:  Choooo  your  NSorNnwotopdon  (cm  OonorM  briontwdon  Mono). 

STEF  4:  Ptapon*  dio  laser  Nbaoring  dw  oudlno.  dolour  going  o  lypNN  bueinetB  laser  Nmwi 

A  Piowide  a  eamaa  noma  (aandart)  in  dm  upper  n0*aomor  boa  of  dm  Naartmad;inchide  phone  number, 
b.  Pm*  dm  document  eonoel  nunbor  undtr  dm  Naertmod  boo. 
a  Pm*  dm  Com  under  dm  documom  conooi  monbor. 

d.  AdNoo»  dm  NtNr  IB  No  indvtduN,  or  Nr «  ponorte  Ndw  inctudi  on  odPuooM  Ino  and  aMRi*  Ino. 

o.  NcNdoUnbaduoMy  paragraph  m  No  NouoNpropodyMMddodNfoddrooQM. 

f.  You  way  wmh  lo  iocm  tio  bodol  mby  (bom  yom  Tmnomrimi  Fowh)  Nr  tig  nlormMcr  ol  dm  roador. 

STEF  4:  Fonoard  dio  Niori  N dio  tocroiwNL  Adondon  EoaaNhnl  1otvmot,uid>acotorNoorroquoodngdbdSudonoldmiomonM 
NMtfs)  you  hoto  pm  pored.  Whan  f»  Noon  haw  boon  Moribund,  to  propa  deNgon  and  Buboowaniiiaa  dor  ad  maewo  an  tpdMd 
TionomOM  Form  ariuch  haa  dto  moRng  daN  and  IbNy  ibom  porNd  Seeing  don  poond. 
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ASC  XI 2-ELECTRONIC  DATA  INTERCHANGE  [EDI) 

Accreooed  Standards  Committee 
ooeratmg  under  the  croc  Mures  of  UO 

American  National  Standards  institute 

Ttm  Jooesey 
(999)999-9999 

Dan  Southey 
(999)999-9999 

Document  No 

ASC  X12C/TG20/90-999 
June  25, 1990 

TO: 

X12  Members  Who  Commented  on  Modifications  to 

X12jcc  Control  Structures 

RE: 

Response  to  Comments  on  December  Ballot 

DMs  205289, 215289, 317289 

Thank  you  foe  your  comment*.  Thii  ballot  involved  modifications  to  X12a  Of  the  327  ballots  mailed,  153  ballots  were 
returned.  Of  these,  81  approved,  15  approved  with  comment,  20  disapproved  with  comment  and  37  abstained 

In  general,  the  vote  responses  were  in  favor  of  the  modifications.  The  majority  of  the  comments  focused  on  the  impact 
of maHMoiiwi  mi  the  fwvweiM  "f  iafarmtiwn  '■  the  *12.32  Dweettwy  The  proposed  modifications 

and  tl»  resulting  p«wt«««in  « «h»  meat  Sreeterj  have  linen  reworked  in  trrpnerr  to  these  mmmrat*  A  revised 
modification  to  X12jb  was  reviewed  by  Technical  Assessment  at  the  June  ASCX12  meeting.  Modifications  to  the 
document  have  been  made  which  reflect  responses  to  the  comments  from  this  ballot,  and  a  revised  copy  of  X12jb  is 
being  distributed  to  all  who  voted  on  this  issue,  for  30-day  review  of  revisions. 

Specific  responses  to  comments  follow. 


COMMENT:  Automobile  Corporation 

‘Add  the  following  note  to  Parspaph  33:  NOTE:  r"*~ protocol  characters  should  be  ciriudrd  from  the 
character  set* 

RESPONSE: 

The  cover  letter  tent  out  with  the  voting  package  explained  that  the  intent  wan  to  obtain  consensus  on  the  proposed 
modifications  to  X12jr.  X12jx  is  a  difficult  standard  to  amend  We  request  that  ballot  responses  be  considered  on  the 
merits  of  the  recommended  modifications  and  act  on  the  standard  at  a  whole.  Your  comment  was  outside  the  scope  of 
the  requested  modifications. 
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COMMENT:  Aircraft  F«gw  Corporation 

"Some  consideration  for  Abstract  Syntax  Notation  One  (ASN.l)  should  be  allowed. 

1.  ASN.l  is  capable  of  defusing  all  of  the  necessary  inter-relations  needed  by  X12  transactions. 

1  ASN.l  requires  leas  characters  to  define  the  same  information. 

3.  ASN.l  is  the  encoding  scheme  used  by  moat  OSI  work.* 

RESPONSE: 

The  recommendation  to  consider  usage  of  ASN.l  reaches  far  beyond  the  scope  of  the  requested 

in  this  ballot.  Activities  such  as  this  are  beat  submitted  as  separate  work  requests. 

COMMENT:  Some  Software  Inc 

Conditionality  of  data  elements  should  be  left  to  the  discretion  of  ■»"pi»—»,afatKKi  guidelines  Blt^  agreements.  There  is 
much  discussion  at  times  as  far  as  whether  certain  data  elements  should  be  mandatory  or  not;  many  application  system 
are  incapable  of  providing  certain  ‘mandatory’  information  and,  as  «««*,  filler-type  <<«»»  must  be  inserted.* 

RESPONSE: 

The  issue  of  data  element  conditionality  as  a  whole  is  a  much  broader  subject  than  wis  intended  to  be  addressed  within 
the  scope  of  this  ballot.  This  ballot  was  to  provide  a  ■»««  for  consistent  *nd  application  of 

already  existing  conditional  structures.  If  the  htTwM  a«i  ts>  «<«iiriwl.i  structure  *»»  <  ft™— 

the  standard,  the  task  group  recommends  that  this  be  submitted  as  a  separate  work  request. 

Ecc. 
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Acerndead  Standards  Comnwtae 

Joe  Somebody 

aperntng  irder  tne  procsdtms  of  tne 

Chair  TG19.X12C 

Amancan  Notional  Standards  maocuta 

(999)999-9999 

Document  No 


Mi  Jane  Doe 
American  Beak 
One  Central  Plaza 
Middle  America,  MO  99999 


ASC  X12C/TG8/90-99RA 
Aufuit  10, 1990 


RE:  Responie  to  Ballot  Comnena  on 
ASC  X12  Model  Guideline 


Dear  Ms.  Doe: 


Suhcnuniftrr  XlTC!  hat  «t T«lr  ru~.p  io  ~ p~ ^  ^  »k.  m  tin.  ^he 

■*nbtn  of  TG19  with  to  thank  all  X12  members  who  took  the  time  and  effort  to  note  on  this  g««ME~  We 
eapedaDy  thank  each  individual  mho  provided  comments,  whether  m  approval  or  disapproval  of  the  guidefiae.  We 
recognarr  and  appreciate  your  careful  review  of  this  document. 

Our  response  is  keyed  to  the  numbered  items  in  the  ««■»«»«  «»iAM  to  yow  Mt<« 

RESPONSE 

1-  We  agree  with  your  comment,  la  Section  422,  me  have  replaced  Nee  utilize  rules  _•  with  'rules  _  me  utilized*. 

2.  The  confusion  between  Section  4L3  and  Section  &2  only  easts  because  of  the  example  me  chose  in  the  first 
*eq*°*-  This  is  a  hypothetical  cample,  of  a  simplified  model  Headers  and  traders  can  be  placed  an  the  content  at 
ALL  levels,  and  do  not  necessarily  correspond  to  ASC  X12  headers  and  miters. 

3.  We  agree  with  your  comment.  Section  &2  has  been  rhsinril  so  that  "the  establishment  of  sms  imUH  to  ^rr»i 
1  and  4. 
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5.0  GLOSSARY 

This  chapter  contains  ASC  X12  and  DoD  specific  glossaries. 

5.1  X12  GLOSSARY 

ANSI 

American  National  Standards  Institute 

ANSI  Standard 

A  document  published  by  ANSI  that  has  been  approved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
of  these  standards  must  have  been  developed  by  an  ANSI  commit¬ 
tee  and  must  be  revisited  by  that  committee  within  5  years  for 
update.  See  Draft  Standard  for  Trial  Use  (DSTU). 

Area  Transaction  Set 

Identifies  a  predefined  area  within  a  transaction  set  (header,  detail, 
summary)  containing  segments  and  their  various  attributes. 

ASC  XI2 

Accredited  Standards  Committee,  X12  comprises  industry  mem¬ 
bers  who  create  EDI  standards  for  submission  to  ANSI  for  sub¬ 
sequent  approval  and  dissemination;  or  for  submission  to  the 
UN/ECE  for  approval  and  submission  of  UN/EDIFACT  stan-dards. 

Authentication 

A  mechanism  which  allows  the  receiver  of  an  electronic  transmis¬ 
sion  to  verify  the  sender  and  the  integrity  of  the  content  of  the 
transmission  through  the  use  of  an  electronic  “key”  or  algorithm 
which  is  shared  by  the  trading  partners.  This  is  sometimes  referred 
to  as  an  electronic  signature. 

Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Conditional  (C) 

A  data  element  requirement  designator  which  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value  or 
presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  computer  processable. 

Control  Segment 

A  Control  Segment  has  the  same  structure  as  a  Data  Segment  but 
is  used  for  transferring  control  information  for  grouping  data 
segments.  Control  Segments  are  Loop  Control  Segments  (LS/LE), 
Transaction  Set  Control  Segments  (ST/SE),  and  Functional  Group 
Control  Segments  (GS/GE),  defined  in  X12.6,  and  Interchange 
Control  Segments  (ISA/IEA/TA1)  defined  in  X12.5. 
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Data  Element 

The  basic  units  of  information  in  the  EDI  standards  containing  a 
set  of  values  that  represent  a  singular  fact.  They  may  be  single¬ 
character  codes,  literal  descriptions,  or  numeric  values. 

Data  Element  Length 

This  is  the  range,  minimum  to  maximum,  of  the  number  of  char¬ 
acter  positions  available  to  represent  the  value  of  a  data  element. 
A  data  element  may  be  of  variable  length  with  range  from  mini¬ 
mum  to  maximum,  or  it  may  be  of  fixed  length  in  which  the 
minimum  is  equal  to  the  maximum. 

Data  Element  Reference  Number 

Reference  number  assigned  to  each  data  element  as  a  unique 
identifier. 

Data  Element  Requirement  Designator 

A  code  defining  the  need  for  a  data  element  value  to  appear  in  the 
segment  if  the  segment  is  transmitted.  The  X12  codes  are  man¬ 
datory  (M),  optional  (O),  or  conditional  (C).  DoD  may  "require" 
a  segment  which  is  optional  by  X12  standards. 

Data  Element  Separator 

A  unique  character  preceding  each  data  element  that  is  used  to 
delimit  data  elements  within  a  segment.  Dod  uses  "*"  as  the 
delimiter. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types:  numeric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

The  delimiters  consist  of  two  levels  of  separators  and  a  terminator. 
The  delimiters  are  an  integral  part  of  the  transferred  data  stream. 
Delimiters  are  specified  in  the  interchange  header  and  may  not  be 
used  in  a  data  element  value  elsewhere  in  the  interchange.  From 
highest  to  lowest  level,  the  separators  and  terminator  are  segment 
terminator  and  data  element  separator. 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organization 
funded  by  ASC  X12  members  which  serves  as  the  Secretariat  for 
X12. 

DSTU 

Draft  Standard  for  Trial  Use.  Represents  a  document  approved  for 
publication  by  the  full  X12  committee  following  membership  con¬ 
sensus  and  subsequent  resolution  of  negative  votes.  (Final  Report 
of  X12  Publications  Task  Group).  The  Draft  EDI  Standard  for 
Trial  Use  document  represents  an  ASC  X12  approved  standard  for 
use  prior  to  approval  by  ANSI.  See  ANSI  Standard. 
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EDI 

Electronic  Data  Interchange.  The  computer  application  to  com¬ 
puter  application  exchange  of  business  information  in  a  standard 
format. 

Electronic  Envelope 

Electronic  information  which  binds  together  a  set  of  transmitted 
documents  being  sent  from  one  sender  to  one  receiver. 

Element  Delimiter 

A  single-character  which  follows  the  segment  identifier  and 
separates  each  data  element  in  a  segment  except  the  last. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functional 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  Segments 

GS/GE  segments  identify  a  specific  functional  group  of  documents 
such  as  purchase  orders. 

Industry  Conventions 

Defines  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  how  to  implement  X12  stand¬ 
ards. 

Interchange  Control  Segments 

ISA/IEA  segments  identify  a  unique  interchange  being  sent  from 
one  sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Structure 

The  interchange  header  and  trailer  segments  envelop  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions:  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  information  for  the  inter¬ 
change,  and  (4)  allows  for  authorization  and  security  information. 
(X12.5) 

Loop 

A  group  of  semantically  related  segments:  these  segments  may  be 
either  bounded  or  unbounded  (X12.6).  The  N1  loop  is  an  example 
of  a  loop,  which  includes  segments  N1  to  PER  for  name  and 
address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element  is  required. 


Mapping 

The  process  of  identifying  the  standard  data  element’s  relationship 
to  application  data  elements. 

Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used  at 
the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
Optional  (O) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element/segment  is  at  the  option 
of  the  sending  party  which  can  be  based  on  the  mutual  agreement 
of  the  interchange  parties. 

Qualifier 

A  data  element  which  identifies  or  defines  a  related  element,  set 
of  elements,  or  a  segment.  The  qualifier  contains  a  code  taken 
from  a  list  of  approved  codes. 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set.  See  Max  Use. 

Security 

System  screening  which  denies  access  to  unauthorized  users  and 
protects  data  from  unauthorized  uses 

Segment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifier,  one  or 
more  data  elements  each  preceded  by  an  element  separator,  and 
ends  with  a  segment  terminator. 

Segment  Directory 

Provides  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifier  for  a  segment  composed  of  a  combination  of 
two  or  three  upper-case  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment.  The  segment 
identifier  is  not  a  data  element.  The  segment  identifier  in 
EDIFACT  is  a  component  data  element  —  part  of  a  composite 
data  element  consisting  of  a  segment  identifier  and  an  explicit 
looping  designator. 
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Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment,  e.g.,  N/L. 

Syntax 

The  grammar  or  rales  which  define  the  structure  of  the  EDI 
standards  (i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules  are 
published  in  ANSI  X12.6. 

Transaction  Set 

The  transaction  set  unambiguously  defines,  in  the  standard  syntax, 
information  of  business  or  strategic  significance  and  consists  of  a 
transaction  set  header  segment,  one  or  more  data  segments  in  a 
specified  order,  and  a  transaction  set  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  first  data  element  of  the  transaction  set  header 
segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard  format  and 
translating  them  to  the  standard. 

Version/Reiease 

Identifies  the  publication  of  the  standard  being  used  for  the  genera¬ 
tion  or  the  interpretation  of  data  in  the  X 12  standard  format.  May 
be  found  in  the  Functional  Group  Header  Segment  (GS)  and  in  the 
Interchange  Control  Header  Segment  (ISA).  See  Control  Segment. 

VICS  Committee 

Voluntary  Interindustry  Communications  Standards  for  Electronic 
Data  Interchange 

X12 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  electronic  data  interchange  (EDI). 

X12.5 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic  inter¬ 
change  through  a  data  transmission,  and  it  provides  a  structure  to 
acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.6 

Application  Control  Structure.  This  standard  describes  the  control 
segments  used  to  envelop  loops  of  data  segments,  to  envelop 
transaction  sets,  and  to  envelop  groups  of  related  transaction  sets. 
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5.2  DoD  GLOSSARY 

AIS 

Automated  Information  Systems 
ASD(P&L) 

Assistant  Secretary  of  Defense  (Production  and  Logistics) 

DES 

Data  Encryption  Standard 
DISA 

Defense  Information  Systems  Agency 

DLA 

Defense  Logistics  Agency 
ISA 

Interchange  Control  Header  Identifier 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  Identifier 
PLUS 

Protection  of  Logistics  Unclassified/Sensitive  Systems 
UN/EDIFACT 

EDIFACT;  Electronic  Data  Interchange  for  Administration,  Com¬ 
merce,  and  Transport 
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